writes Great Customer Technical Documents

I've seen tech writers who concentrate on "look and feel" so much that they fail to communicate, and some of those writers get somewhat overwhelmed by the technical research required. As for me, I like figuring out how the product works (hardware, software or robotics) as much as I like figuring out how to present those details to the customer.

 

I could parse these issues -- how the product works vs. how to use the product, casual user vs. super-user vs. reference -- but all of this depends on who is using the information, how they're using it, and what delivery system best gets them what they need (manual, tutorial, video, interlinked Web knowledge base, etc.).

 

The software you use can control the formatting. One very well-known software package is ugly for formatting. It is designed to change the formatting for every computer. However, this same software is extremely useful for reviews and otherwise making the information available to the team while the information is in development. The bottom line is, the software I use to develop the documents at first may not be the software I use a few years down the road. Later, the docs development group may be larger and the information-gathering and review tools can be more sophisticated, specialized and stable. I tend to base software decisions on stability, cost and how easy it is for the team to contribute.

 

Because I think the final product (manual, video, installation instructions, whatever) represents the whole company, I’m convinced that everybody who has a stake should be able to be part of the development process if they want to.

 

I want to give you a little bit of my philosophy on tech docs, and to say that I think I can offer a better experience than a writer who concentrates on formatting to the exclusion of effectively getting your technical info to your customers when they need it.